home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc1273.txt < prev    next >
Text File  |  1994-08-01  |  20KB  |  451 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        M. Schwartz
  8. Request for Comments: 1273                        University of Colorado
  9.                                                            November 1991
  10.  
  11.  
  12.                    A Measurement Study of Changes in
  13.                 Service-Level Reachability in the Global
  14.               TCP/IP Internet: Goals, Experimental Design,
  15.                Implementation, and Policy Considerations
  16.  
  17. Status of this Memo
  18.  
  19.    This memo provides information for the Internet community.  It does
  20.    not specify an Internet standard.  Distribution of this memo is
  21.    unlimited.
  22.  
  23. Abstract
  24.  
  25.    In this report we discuss plans to carry out a longitudinal
  26.    measurement study of changes in service-level reachability in the
  27.    global TCP/IP Internet.  We overview our experimental design,
  28.    considerations of network and remote site load, mechanisms used to
  29.    control the measurement collection process, and network appropriate
  30.    use and privacy issues, including our efforts to inform sites
  31.    measured by this study.  A list of references and information on how
  32.    to contact the Principal Investigator are included.
  33.  
  34. Introduction
  35.  
  36.    The global TCP/IP Internet interconnects millions of individuals at
  37.    thousands of institutions worldwide, offering the potential for
  38.    significant collaboration through network services and electronic
  39.    information exchange.  At the same time, such powerful connectivity
  40.    offers many avenues for security violations, as evidenced by a number
  41.    of well publicized events over the past few years.  In response, many
  42.    sites have imposed mechanisms to limit their exposure to security
  43.    intrusions, ranging from disabling certain inter-site services, to
  44.    using external gateways that only allow electronic mail delivery, to
  45.    gateways that limit remote interactions via access control lists, to
  46.    disconnection from the Internet.  While these measures are preferable
  47.    to the damage that could occur from security violations, taken to an
  48.    extreme they could eventually reduce the Internet to little more than
  49.    a means of supporting certain pre-approved point-to-point data
  50.    transfers.  Such diminished functionality could hinder or prevent the
  51.    deployment of important new types of network services, impeding both
  52.    research and commercial advancement.
  53.  
  54.    To understand the evolution of this situation, we have designed a
  55.  
  56.  
  57.  
  58. Schwartz                                                        [Page 1]
  59.  
  60. RFC 1273                  A Measurement Study              November 1991
  61.  
  62.  
  63.    study to measure changes in Internet service-level reachability over
  64.    a period of one year.  The study considers upper layer service
  65.    reachability instead of basic IP connectivity because the former
  66.    indicates the willingness of organizations to participate in inter-
  67.    organizational computing, which will be an important component of
  68.    future wide area distributed applications.
  69.  
  70.    The data we gather will contribute to Internet research and
  71.    engineering planning activities in a number of ways.  The data will
  72.    indicate the mechanisms sites use to distance themselves from
  73.    Internet connectivity, the types of services that sites are willing
  74.    to run (and hence the type of distributed collaboration they are
  75.    willing to support), and variations in these characteristics as a
  76.    function of geographic location and type of institution (commercial,
  77.    educational, etc.).  Understanding these trends will allow
  78.    application designers and network builders to more realistically plan
  79.    for how to support future wide area distributed applications such as
  80.    digital library systems, information services, wide area distributed
  81.    file systems, and conferencing and other collaboration-support
  82.    systems.  The measurements will also be of general interest, as they
  83.    represent direct measurements of the evolution of a global electronic
  84.    society.
  85.  
  86.    Clearly, a study of this nature and magnitude raises a number of
  87.    potential concerns.  In this note we overview our experimental
  88.    design, considerations of network and remote site load, mechanisms
  89.    used to control the measurement collection process, and our efforts
  90.    to inform sites measured by this study, along with concomitant
  91.    network appropriate use and privacy issues.
  92.  
  93.    A point we wish to stress from the outset is that this is not a study
  94.    of network security.  The experiments do not attempt to probe the
  95.    security mechanisms of any machine on the network.  The study is
  96.    concerned solely with the evolution of network connectivity and
  97.    service reachability.
  98.  
  99. Experimental Design
  100.  
  101.    The study consists of a set of runs of a program over the span of one
  102.    to two days each month, repeated bimonthly for a period of one year
  103.    (in January 1992, March 1992, May 1992, July 1992, September 1992,
  104.    and November 1992).  Each program run attempts to connect to 13
  105.    different TCP services at each of approximately 12,700 Internet
  106.    domains worldwide, recording the failure/success status of each
  107.    attempt.  The program will attempt no data transfers in either
  108.    direction.  If a connection is successful, it is simply closed and
  109.    counted.  (Note in particular that this means that the security
  110.    mechanism behind individual network services will not be tested.)
  111.  
  112.  
  113.  
  114. Schwartz                                                        [Page 2]
  115.  
  116. RFC 1273                  A Measurement Study              November 1991
  117.  
  118.  
  119.    The machines on which connections are attempted will be selected at
  120.    random from a large list of machines in the Internet, constrained
  121.    such that at most 1 to 3 machines is contacted in any particular
  122.    domain.
  123.  
  124.    The services to which connections will be attempted are:
  125.  
  126.     __________________________________________________________________
  127.       Port Number   Service                Port Number   Service
  128.     ------------------------------------------------------------------
  129.           13        daytime                    111       Sun portmap
  130.           15        netstat                    513       rlogin
  131.           21        FTP                        514       rsh
  132.           23        telnet                     540       UUCP
  133.           25        SMTP                       543       klogin
  134.           53        Domain Naming System       544       krcmd, kshell
  135.           79        finger
  136.      _________________________________________________________________
  137.  
  138.    This list was chosen to span a representative range of  service
  139.    types, each of which can be expected to be found on any machine in a
  140.    site (so that probing random machines is meaningful).  The one
  141.    exception  is  the  Domain  Naming  System,  for which the machines
  142.    to probe are selected from information  obtained  from the  Domain
  143.    system itself.  Only TCP services are tested, since the TCP
  144.    connection mechanism  allows  one  to  determine  if  a server is
  145.    running in an application-independent fashion.
  146.  
  147.    As an aside, it would be possible  to  retrieve  "Well  Known
  148.    Service"  records  from the Domain Naming System, as a somewhat less
  149.    "invasive" measurement approach.  However,  these  records are  not
  150.    required  for proper network operation, and hence are far from
  151.    complete or consistent in the  Domain  Naming  System.  The  only way
  152.    to collect the data we want is to measure them in the fashion
  153.    described above.
  154.  
  155. Network and Remote Site Load
  156.  
  157.    The measurement software is quite careful to avoid generating
  158.    unnecessary internet packets, and to avoid congesting the internet
  159.    with too much concurrent activity.  Once it has successfully
  160.    connected to a particular service in a domain, the software never
  161.    attempts to connect to that service on any machine in that domain
  162.    again, for the duration of the current measurement run (i.e., the
  163.    current 60 days).  Once it has recorded 3 connection refusals at any
  164.    machines in that domain for a service, it does not try that service
  165.    at that domain again during the current measurement run.  If it
  166.    experiences 3 timeouts on any machine in a domain, it gives up on the
  167.  
  168.  
  169.  
  170. Schwartz                                                        [Page 3]
  171.  
  172. RFC 1273                  A Measurement Study              November 1991
  173.  
  174.  
  175.    domain, possibly to be retried again a day later (to overcome
  176.    transient network problems).  In the worst case there will be 3
  177.    connection failures for each service at 3 different machines, which
  178.    amounts to 37 connection requests per domain (3 for each of the 12
  179.    services other than the Domain Naming System, and one for the Domain
  180.    Naming System).  However, the average will be much less than this.
  181.  
  182.    To quantify the actual Internet load, we now present some
  183.    measurements from test runs of the measurement software that were
  184.    performed in August 1991.  In total, 50,549 Domain Naming System
  185.    lookups were performed, and 73,760 connections were attempted.  This
  186.    measurement run completed in approximately 10 hours, never initiating
  187.    more than 20 network operations (name lookups or connection attempts)
  188.    concurrently.  The total NSFNET backbone load from all traffic
  189.    sources that month was approximately 5 billion packets.  Therefore,
  190.    the traffic from our measurement study amounted to less than .5% of
  191.    this volume on the day that the measurements were collected.  Since
  192.    the Internet contains several other backbones besides NSFNET, the
  193.    proportionate increase in total Internet traffic was significantly
  194.    less than .5%.
  195.  
  196.    The cost to a remote site being measured is effectively zero.  From
  197.    the above measurements, on average we attempted 5.7 connections per
  198.    remote domain.  The cost of a connection open/close sequence is quite
  199.    small, particularly when compared to the cost of the many electronic
  200.    mail and news transmissions that most sites experience on a given
  201.    day.
  202.  
  203. Control Over Measurement Collection Process
  204.  
  205.    The measurement software evolved from an earlier set of experiments
  206.    used to measure the reach of an experimental Internet white pages
  207.    tool called netfind [Schwartz & Tsirigotis 1991b], and has been
  208.    evolved and tested extensively over a period of two years.  During
  209.    this time it has been used in a number of experiments of increasing
  210.    scale.  The software uses several redundant checks and other
  211.    mechanisms to ensure that careful control is maintained over the
  212.    network operations that are performed [Schwartz & Tsirigotis 1991a].
  213.    In addition, we monitor the progress and network loading of the
  214.    measurements during the measurement runs, observing the log of
  215.    connection requests in progress as well as physical and transport
  216.    level network status (which indicate the amount of concurrent network
  217.    activity in progress).  Finally, because the measurements are
  218.    controlled from a single centralized location, it is quite easy to
  219.    stop the measurements at any time.
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Schwartz                                                        [Page 4]
  227.  
  228. RFC 1273                  A Measurement Study              November 1991
  229.  
  230.  
  231. Network Appropriate Use and Privacy Issues
  232.  
  233.    When we performed our initial test runs of this study, we attempted
  234.    to inform site administrators at each study site about this study, by
  235.    posting a message on the USENET newsgroup "alt.security" and by
  236.    sending individual electronic mail messages to site administrators.
  237.    We also informed the Computer Emergency Response Team (CERT) at CMU
  238.    of the study.  As a practical matter, informing all sites turned out
  239.    to be quite difficult.  Part of the problem was that no channels
  240.    exist to allow such information to be easily disseminated.
  241.    Approximately half of the messages we sent to site administrators
  242.    were returned by remote mail systems as undeliverable.  Moreover, the
  243.    network traffic and remote site administrative load caused by the
  244.    study announcement messages far outstripped the network and
  245.    administrative load required by the study itself.  Some sites felt
  246.    that the announcement was an unnecessary imposition of their time.
  247.  
  248.    In addition to these practical problems, a broad announcement of this
  249.    study could affect the measurements it attempts to gather.  Some
  250.    sites would likely react to the announcement by changing the
  251.    reachability of their services.  Asking for explicit permission from
  252.    sites would yield even worse methodological problems, as this would
  253.    have provided a self-selected study group consisting of sites that
  254.    are less likely to disconnect from the Internet.
  255.  
  256.    In contrast with our attempts to announce the study, running the
  257.    study without announcing it caused only a small number of site
  258.    administrators to notice the traffic and inquire about it to either
  259.    the CERT or to one of the responsible network contacts at the
  260.    University of Colorado.  The remote site administrator and network
  261.    overhead of announcing the the study, coupled with the practical and
  262.    methodological problems of announcing the study, lead us to prefer to
  263.    run the study without further broad announcements.  Yet, to avoid
  264.    causing alarm at a site detecting our network measurement activity,
  265.    it makes sense to announce the study.
  266.  
  267.    To resolve this problem, we discussed the study with the Internet
  268.    Activities Board, Internet Engineering Steering Group, National
  269.    Science Foundation, representatives of several U.S.  regional
  270.    networks, and a number of individuals involved with network security,
  271.    including the Computer Emergency Response Team, members of the
  272.    Internet Engineering Task Force Security and Advisory Group, and a
  273.    member of the Lawrence Livermore National Laboratory Computer
  274.    Incident Advisory Capability.  The first part of our efforts resulted
  275.    in the production of Internet Request For Comments (RFC) number 1262
  276.    [Cerf 1991].  Beyond this, we have agreed that the appropriate action
  277.    at this point is to announce the study well ahead of running it via
  278.    the current RFC, augmented with an electronic posting that briefly
  279.  
  280.  
  281.  
  282. Schwartz                                                        [Page 5]
  283.  
  284. RFC 1273                  A Measurement Study              November 1991
  285.  
  286.  
  287.    describes the study goals and methodology and points to this RFC.
  288.    That announcement will be posted to the Internet Engineering Task
  289.    Force mailing list, the comp.protocols.tcp-ip USENET bulletin board,
  290.    and the Computer Emergency Response Team's cert-tools mailing list.
  291.    Moreover, in case a site misses these announcements, we will run the
  292.    measurement software in a fashion intended to minimize the effort a
  293.    site administrator might expend to determine the nature of the
  294.    activity after detecting it.  In particular, we will run the program
  295.    from an account called "testnet" on a machine with few other users
  296.    logged in.  "Fingering" [Zimmerman 1990] this machine will indicate
  297.    the testnet login.  "Fingering" the testnet login will return
  298.    information about this study.
  299.  
  300.    The data collected by this study is somewhat sensitive to privacy and
  301.    security concerns, in the sense that it might be used as a "road map"
  302.    of accessible network services.  We will treat the raw data as
  303.    private information, publishing measurements only in global
  304.    statistical terms, divorced from the actual sites that make up the
  305.    underlying data points.  We previously carried out a study with much
  306.    larger privacy implications than the current study [Schwartz & Wood
  307.    1991], and successfully masked the data to protect individual
  308.    privacy.
  309.  
  310. For Further Information
  311.  
  312.    Information about the general research program within which this
  313.    study fit is available by anonymous FTP from latour.cs.colorado.edu,
  314.    in pub/RD.Papers.  This directory contains a "README" file that
  315.    describes the overall research project (which focuses on resource
  316.    discovery), and includes a bibliography.  Particularly relevant are:
  317.  
  318.       o [Schwartz 1991b], a project overview;
  319.  
  320.       o [Schwartz 1991a], about an earlier, simpler  version  of  the
  321.         current study;
  322.  
  323.       o [Schwartz & Tsirigotis 1991b], about the netfind white  pages
  324.         tool;
  325.  
  326.       o [Schwartz & Tsirigotis 1991a], which considers  a  number  of
  327.         the  techniques  used in this experiment, including those for
  328.         controlling the progress of the measurements;
  329.  
  330.         and
  331.  
  332.       o [Schwartz & Wood 1991], about an earlier study we carried out
  333.         that  raises  significant  potential  privacy  questions, for
  334.         which we carefully masked the underlying data, presenting the
  335.  
  336.  
  337.  
  338. Schwartz                                                        [Page 6]
  339.  
  340. RFC 1273                  A Measurement Study              November 1991
  341.  
  342.  
  343.         results without sacrificing individual privacy.
  344.  
  345.         Also:
  346.  
  347.       o [Cerf  1991],  IAB  guidelines   for   Internet   measurement
  348.         activity.
  349.  
  350.    Once the results of this study are complete, we will publish them in
  351.    a conference or journal, as well as by anonymous FTP.
  352.  
  353. Communication With Principal Investigator
  354.  
  355.    If you would like to have your site removed from this study, or you
  356.    would like to be added to the list of people who receive results from
  357.    this study, or you would like to communicate with the Principal
  358.    Investigator for some other reason, please send electronic mail to
  359.    schwartz@cs.colorado.edu.
  360.  
  361. References
  362.  
  363.    [Cerf 1991]
  364.              Cerf, V., Editor, "Guidelines for Internet Measurement
  365.              Activities", RFC 1262, IAB, October 1991.
  366.  
  367.    [Schwartz & Tsirigotis 1991a]
  368.              Schwartz M., and P. Tsirigotis, "Techniques for
  369.              Supporting Wide Area Distributed Applications", Technical
  370.              Report CU-CS-519-91, Department of Computer Science,
  371.              University of Colorado, Boulder, Colorado, February 1991;
  372.              Revised August 1991.  Submitted for publication.
  373.  
  374.    [Schwartz & Tsirigotis 1991b]
  375.              Schwartz M., and P. Tsirigotis "Experience with a
  376.              Semantically Cognizant Internet White Pages Directory
  377.              Tool", Journal of Internetworking: Research and Experience,
  378.              2(1), pp. 23-50, March 1991.
  379.  
  380.    [Schwartz 1991a]
  381.              Schwartz, M., "The Great Disconnection?", Technical Report
  382.              CU-CS-521-91, Department of Computer Science, University of
  383.              Colorado, Boulder, Colorado, February 1991.
  384.  
  385.    [Schwartz & Wood 1991]
  386.              Schwartz M., and D. Wood, "A Measurement Study of
  387.              Organizational Properties in the Global Electronic Mail
  388.              Community", Technical Report CU-CS- 482-90, Department of
  389.              Computer Science, University of Colorado, Boulder, Colorado,
  390.              August 1990; Revised July 1991.  Submitted for publication.
  391.  
  392.  
  393.  
  394. Schwartz                                                        [Page 7]
  395.  
  396. RFC 1273                  A Measurement Study              November 1991
  397.  
  398.  
  399.    [Schwartz 1991b]
  400.              Schwartz, M., "Resource Discovery in the Global Internet",
  401.              Technical Report CU-CS-555-91, Department of Computer
  402.              Science, University of Colorado, Boulder, Colorado,
  403.              November 1991.  Submitted for publication.
  404.  
  405.    [Zimmerman 1990]
  406.              Zimmerman, D., "The Finger User Information Protocol",
  407.              RFC 1194, Center for Discrete Mathematics and Theoretical
  408.              Computer Science, November 1990.
  409.  
  410. Security Considerations
  411.  
  412.    Security issues are discussed in the "Network Appropriate Use and
  413.    Privacy Issues" section.
  414.  
  415. Author's Address
  416.  
  417.    Michael F. Schwartz
  418.    Department of Computer Science
  419.    Campus Box 430
  420.    University of Colorado
  421.    Boulder, Colorado 80309-0430
  422.  
  423.    Phone:  (303) 492-3902
  424.  
  425.    EMail: schwartz@cs.colorado.edu
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Schwartz                                                        [Page 8]
  451.